El otro día actualicé mi entorno de Python con uv y ni me paré a pensar que estaba escrito en Rust. Busqué una función en un proyecto que no conocía con ripgrep y la respuesta llegó antes de que soltara el teclado. Y entre medias, sin que nadie me avisara, mi sistema había cambiado de idioma por debajo.
No soy el único al que le ha pasado. En diciembre de 2025 los mantenedores del kernel de Linux se reunieron en Tokio y acordaron algo que llevaba años en el aire: Rust deja de ser «experimental» dentro del kernel. Ubuntu 25.10 trae por defecto sudo-rs en vez del sudo de toda la vida. Debian ha anunciado que, a partir de mayo de 2026, APT el gestor de paquetes que hay debajo de media internet dependerá de Rust de forma obligatoria, y a las arquitecturas que no tengan un compilador Rust les da seis meses para buscarse la vida. Microsoft está reescribiendo partes de Windows y de su librería criptográfica. Y en Bun se pasaron once días convirtiendo medio millón de líneas de Zig en Rust usando decenas de agentes de Claude en paralelo.
Nada de esto lo decidió nadie de un plumazo. Fue pasando: una herramienta sustituyó a otra, una librería cambió por debajo de un comando que llevabas usando años, y un día te encuentras con que media caja de herramientas habla un idioma distinto. Vale la pena pararse a mirar los números reales detrás de este movimiento, lo que ha costado a quien lo ha probado y por qué, pese a todo, ni C++ ni Go ni Zig ni Swift ni Kotlin se han quedado quietos mirando.
El fallo que Rust elimina de raíz
La seguridad de memoria es una garantía muy concreta: que un programa no pueda leer ni escribir en una zona de memoria que no le pertenece. Cuando un programa en C o C++ se pasa de la raya en un array, o sigue usando un trozo de memoria después de haberlo liberado, aparecen los fallos con nombre propio: buffer overflow, use-after-free. No son errores de lógica, el programa hace exactamente lo que le has dicho que haga. Son fallos de permisos que el lenguaje nunca llega a comprobar.
Durante años esto se aceptó como el precio de la velocidad. Y entonces empezaron a salir las cifras. Microsoft lleva desde 2019 repitiendo el mismo dato en sus charlas de seguridad: de las vulnerabilidades graves que ha parcheado en más de una década, un 70% son fallos de memoria. Chromium analizó 912 bugs de severidad alta o crítica desde 2015 y llegó al mismo porcentaje casi calcado, con el use-after-free como protagonista de la mitad de los casos.
El experimento más limpio que tenemos es Android. Google empezó a escribir código nuevo en Rust dejando el C y el C++ existentes tal cual estaban, sin tocarlos. En 2019, el 76% de las vulnerabilidades de Android eran fallos de memoria. En 2024 esa cifra había bajado al 24%, y a finales de 2025 ya estaba por debajo del 20%. Sin reescritura heroica de nada: simplemente un lenguaje distinto por defecto para el código nuevo, mientras el código viejo se iba quedando quieto y sus bugs dejaban de sumar.
Hay cifras ahí dentro que todavía me cuesta digerir del todo. El código Rust de Android tiene, según Google, una densidad de vulnerabilidades de memoria unas mil veces menor que su C y C++. Los cambios en Rust se revierten cuatro veces menos que los del resto del código, y pasan un 25% menos de tiempo en revisión antes de fusionarse. Ese último dato me da vueltas: el lenguaje con fama de pelearse contigo en cada línea produce cambios que, al parecer, generan menos discusión al revisarlos.
La lista de quien ya se ha subido al carro
El kernel de Linux llevaba desde 2022 con soporte Rust en la rama principal, pero era una vía experimental. En la Kernel Maintainer Summit de diciembre de 2025 se decidió quitarle esa etiqueta: Rust pasa a ser, en sus propias palabras, «parte central del kernel, y ha venido para quedarse». El primer aviso de que esto tiene fricciones reales llegó poco después: el primer CVE en código Rust del kernel, una condición de carrera en el driver Binder que provoca un cuelgue, no un fallo de seguridad de memoria propiamente dicho. Y ocurrió, esto es lo interesante, dentro de un bloque marcado como unsafe. Ya volveremos sobre esto.
Ubuntu 25.10 lleva sudo-rs por defecto, aunque el sudo clásico sigue disponible si lo prefieres. La sorpresa está en la siguiente LTS: Ubuntu 26.04 ya trae de serie las utilidades de uutils reescritas en Rust en vez de las GNU coreutils de toda la vida, salvo cp, mv y rm, que se quedan en su versión original por precaución. Debian, por su parte, ha anunciado que APT dependerá de Rust de forma obligatoria desde mayo de 2026, para el parseo de paquetes .deb y la verificación criptográfica vía Sequoia. Las arquitecturas sin compilador Rust (m68k, hppa, sh4, Alpha) tienen seis meses de margen antes de quedar fuera.
Microsoft ha portado el motor de regiones gráficas de win32k a Rust, y ha reescrito SymCrypt, su librería criptográfica, verificando formalmente el código con herramientas como Aeneas y Lean. No es casualidad que empezaran por ahí: parseo de fuentes y criptografía son, históricamente, dos de los sitios donde más ha dolido un fallo de memoria.
En el mundo Python, uv ya supera los 126 millones de descargas mensuales en PyPI y fue la herramienta más valorada en la encuesta de Stack Overflow de 2025. El 19 de marzo de 2026, OpenAI anunció la compra de Astral, la empresa detrás de uv y ruff. En el lado de JavaScript, Vite 8 ha sustituido su motor interno por Rolldown y Oxc, ambos en Rust: en el benchmark propio del equipo, un build de 19.000 módulos pasa de 40 segundos a poco más de 1,6.
Y luego está Bun, que es el caso más ruidoso de todos. En julio de 2026 el equipo anunció que había traducido 1.448 archivos y más de 535.000 líneas de Zig a Rust en once días, apoyándose en agentes de Claude corriendo en paralelo, a un coste estimado de unos 165.000 dólares en tokens. El consumo de memoria tras 2.000 builds bajó de 6,7 GB a 609 MB. Andrew Kelley, creador de Zig, calificó el resultado de «basura sin revisar». Tiene razón en algo: meses después, ese código en Rust seguía siendo un experimento paralelo, sin fecha de lanzamiento, mientras el binario que la gente sigue instalando es el de Zig.
Hay una fecha de por medio
Lo que mueve kernels y librerías criptográficas no es solo convicción técnica, también hay presupuestos y responsabilidad legal encima de la mesa. Y esto último es lo que más acelera las cosas.
El 26 de febrero de 2024, la Oficina del Director Nacional de Ciberseguridad de la Casa Blanca (ONCD) publicó un informe pidiendo a la industria que empezara a abandonar los lenguajes sin seguridad de memoria en el software crítico. La ONCD no tiene poder para obligar a nadie, escribe estrategia, no la ejecuta. Pero después llegó algo con más dientes: en octubre de ese mismo año, CISA y el FBI publicaron una guía pidiendo a los operadores de infraestructura crítica que tuvieran listo, antes del 1 de enero de 2026, un «memory safety roadmap»: qué partes de su software son inseguras a nivel de memoria, cuáles dan la cara al público o manejan criptografía, y cuándo piensan arreglarlo.
Esa fecha ya ha pasado. El documento no obliga a nada por ley, pero ya se está colando en cuestionarios de seguridad de clientes y en el papeleo de fusiones y adquisiciones. Un código en C++ sin plan de migración es, a estas alturas, una pregunta que un cliente tiene todo el derecho a hacer.
Lo que cuesta de verdad reescribir algo
Aquí conviene frenar antes de convertir esto en un anuncio publicitario de Rust.
Las reescrituras pequeñas se llevan meses. Las medianas, entre uno y dos años. Las grandes pueden estirarse de dos a cinco, y bastantes se quedan a medias. Prisma anunció en noviembre de 2025 que su motor de consultas, escrito en Rust, volvía a TypeScript: la razón oficial no fue tanto la dificultad de encontrar gente que supiera Rust como el rendimiento y el tamaño del bundle, hasta tres veces más rápido en consultas y con un 85-90% menos de peso al compilar a WebAssembly. Loglog Games abandonó Rust tras tres años de videojuego con un veredicto que se me quedó grabado: «excelente para refactorizar, malo para ir probando cosas rápido». Y curl estuvo a punto de adoptar hyper, la librería HTTP en Rust, llegó al 95% y se quedó ahí: según su propio creador, Daniel Stenberg, no hay suficiente gente que use curl y a la vez quiera trabajar en un proyecto en Rust como para sostenerlo.
El caso que más me hace pensar es el del compilador nativo de TypeScript. Microsoft lo reescribió desde cero para que compilara más rápido, y en pleno año de mayor presión hacia Rust, eligieron Go. No porque Rust rindiera peor, sino porque necesitaban un port que mantuviera la semántica exacta del compilador original, con los mismos mensajes de error, y las referencias circulares tan propias de un compilador se resolvían en Rust escribiendo, en la práctica, tu propio recolector de basura por encima del lenguaje. Uno de los proyectos más vigilados del mundo miró a Rust de frente y dijo que no, con motivos técnicos de peso.
Rust contra sus rivales
Rust no compite en el vacío. Cada uno de sus rivales tiene una respuesta distinta al mismo problema, y ninguna es tan simple como «Rust gana siempre».
Go: el que ya construyó la infraestructura que Rust quiere heredar
Docker, Kubernetes, Terraform, Prometheus, Helm: la infraestructura cloud que ya existe está mayoritariamente escrita en Go, gracias a su concurrencia sencilla y a tiempos de compilación muy cortos. Rust está ganando terreno en la capa de rendimiento crítico que hay debajo de esa infraestructura Cloudflare, por ejemplo, sustituyó buena parte de su gestión de peticiones por Rust, pero no siempre gana por rendimiento puro. Discord reescribió un servicio concreto de Go a Rust porque el recolector de basura provocaba picos de latencia al recorrer una caché en memoria con millones de entradas: ahí sí, el garbage collector fue el problema, no una cuestión de gustos. Curiosamente, en el índice TIOBE de mayo de 2026 Go cayó de la posición 7 a la 16, mientras Rust entraba por primera vez en el top 10 en julio de ese mismo año.
Zig: la simplicidad como respuesta, no el borrado de reglas
Zig apuesta por la seguridad mediante control explícito y manual, sin ocultar el flujo del programa detrás de reglas de compilación complejas como el borrow checker. Bun se escribió originalmente en Zig por ese mismo motivo. Y aun así, su creador acabó cansado de perseguir fugas de memoria y cuelgues a mano, que es justo lo que empujó la migración a Rust. Zig, además, sigue sin llegar a la versión 1.0 en 2026 (la última estable es la 0.16.0, de abril), y su propio creador reconoce que un 1.0 acercaría clientes corporativos, pero prefiere no forzarlo mientras el proyecto pueda sostenerse con donaciones.
C++: el comité elige la vía lenta
La propuesta «Safe C++» de Sean Baxter, que añadía un borrow checker al estilo Rust directamente al lenguaje, perdió la votación del comité de seguridad de C++ en febrero de 2025 frente a «Profiles», la alternativa de Bjarne Stroustrup: reglas incrementales, activables módulo a módulo, que prohíben patrones peligrosos sin reescribir el lenguaje entero. El problema es que Profiles tampoco entró en el estándar C++26 el propio Stroustrup admite que el comité «se hizo un lío» y ahora se apunta a C++29. Mientras tanto, Chromium tira de parches como MiraclePtr, que según Google ha neutralizado el 57% de los use-after-free en sus procesos con más privilegios. Es una venda, no una cura, pero explica por qué C++ sigue mandando en videojuegos, computación de alto rendimiento y en todo el código heredado que nadie se atreve a tocar.
Swift: la memoria segura sin borrow checker
Swift resuelve la gestión de memoria con ARC, conteo automático de referencias, que es invisible en el código del día a día y no obliga al programador a razonar sobre propietarios y préstamos como en Rust. La contrapartida es que ARC no evita ciclos de referencias ni condiciones de carrera, porque no está codificado en el sistema de tipos como en Rust. Los benchmarks de 2026 sitúan a Rust entre dos y diez veces más rápido, y con bastante menos consumo de memoria en tiempo de ejecución. El servidor en Swift (Vapor) sigue siendo un ecosistema mucho más delgado que Axum o Tokio en Rust, con menos middleware y menos gente disponible para contratar, así que para un backend nuevo la balanza suele caer del lado de Rust por motivos más operativos que técnicos.
Kotlin: el vecino con el que no hay pelea
Aquí esperaba encontrar más tensión de la que hay. La comunidad de Kotlin apenas habla de Rust como rival: son lenguajes que compiten en capas distintas del mismo stack, y el propio Google institucionalizó esa división en Android. Kotlin sigue siendo el lenguaje oficial para las apps, mientras el código de sistema drivers, componentes del núcleo se escribe cada vez más en Rust. El blog oficial de JetBrains compara Rust contra Java, no contra Kotlin, y su informe de octubre de 2025 sobre el ecosistema de desarrolladores lo resume bien: la gente no se pasa a Kotlin porque tenga que hacerlo, sino porque se siente mejor trabajando con él, mientras que a Rust se llega sobre todo huyendo de código de sistemas inseguro escrito en C o C++. Son dos curvas de adopción con motores distintos, no una carrera por el mismo público.
El interruptor que apaga la seguridad
Rust deja abierta la puerta para desactivar su propia garantía. Se llama unsafe, y hace exactamente lo que promete: dentro de un bloque marcado así, el compilador deja de vigilar las reglas que hacen a Rust seguro en memoria. Puedes desreferenciar un puntero crudo, llamar directamente a una librería en C, y el borrow checker se aparta y confía en tu palabra.
Esto no es un descuido, tiene que existir. Tarde o temprano un programa necesita hablar con el hardware, o con un sistema operativo escrito en C, o con una librería que nadie va a reescribir jamás. Un lenguaje que no pudiera hacer eso no podría correr un kernel, que es justo por lo que Linux y Windows pueden meter Rust dentro.
La letra pequeña es que el trabajo peligroso sigue concentrado, precisamente, en el código que renunció a la comprobación. Y lo que sí ganas a cambio es un mapa: buscar unsafe en un proyecto Rust que no conoces te da la lista de sitios sospechosos antes de comer. Treinta años de C te entregan el repositorio entero y te desean suerte. Tener la lista no es lo mismo que haberla revisado, pero al menos existe y se puede buscar.
Cuando el ataque no es de memoria, es de confianza
El 20 de agosto de 2026, alguien publicó versiones maliciosas de tres paquetes de crates.io, el repositorio de Rust: arrayref, internment y append-only-vec, usando credenciales robadas de sus mantenedores. Las versiones envenenadas tiraban de un paquete falso llamado proc-macro1, que imitaba al real proc-macro2, y su script de compilación descargaba una segunda fase de malware en el propio momento de compilar. Solo arrayref acumula 245 millones de descargas históricas. El equipo de seguridad de Rust retiró las versiones maliciosas entre 86 y 107 minutos después de publicarse, a raíz de un aviso de Nextron Systems: una respuesta rapidísima para los tiempos que se manejan en este tipo de incidentes. La empresa Wiz encontró después solapamientos de infraestructura con campañas atribuidas a Corea del Norte, aunque conviene ser precisos aquí: es un indicio de infraestructura compartida, no una atribución confirmada por ningún organismo.
Nada de esto tiene que ver con la seguridad de memoria. El borrow checker no comprueba credenciales robadas ni scripts de compilación que ejecutan lo que les da la gana en tu máquina. Es el mismo guion que ya hemos visto en npm, en React, en LiteLLM: el punto débil sigue siendo la confianza que le damos por defecto a las dependencias, y da igual en qué lenguaje esté escrito el ecosistema.
Y encima los modelos de lenguaje han abierto una vía nueva para el mismo problema. Un estudio académico presentado en USENIX Security 2025, con más de 576.000 muestras, encontró que un 19,7% de los nombres de paquetes que sugieren los modelos de IA no existen, y que un 43% de esas invenciones se repiten de forma idéntica en distintas ejecuciones del mismo prompt. Ese dato de la reproducibilidad es el que de verdad preocupa: un nombre inventado una sola vez es ruido, pero uno estable es un hueco que alguien puede registrar y esperar a que caiga gente. En Corea del Norte ya han montado una campaña, PromptMink, con README de npm escritos para sonar convincentes a un modelo de lenguaje más que a una persona, sin necesidad de ningún jailbreak ni inyección de prompt: basta con que el agente confíe en la documentación.
Y por si hacía falta subir la apuesta: en noviembre de 2025, Anthropic hizo público que había frenado lo que describe como la primera campaña de ciberespionaje orquestada por IA, un grupo patrocinado por el estado chino que había manipulado Claude Code para ejecutar intrusiones contra una treintena de objetivos, con el modelo llevando entre el 80% y el 90% de la operación de forma autónoma.
Qué hacer con esto el lunes
Si mantienes código en C o C++ en algo que importe, este es el sitio por donde empezar, y conviene arrancar por el papeleo antes que por el código. Haz la lista de qué componentes están escritos en un lenguaje sin seguridad de memoria, marca los que dan la cara al público o manejan criptografía, y ponle fecha a los dos peores. Con eso cubres la mayor parte de lo que pide CISA, y prefiero redactarlo un jueves tranquilo que con un auditor esperando al otro lado del teléfono.
Si escribes en Rust, el equipo de seguridad del lenguaje publicó un comando para comprobar si alguna de las versiones comprometidas del ataque de agosto llegó a pasar por tu caché local de cargo. Merece la pena correrlo aunque estés bastante seguro de que no. Y échale un vistazo a qué hacen los build.rs de tus dependencias, porque ejecutan código arbitrario en el momento de compilar con tus propios permisos, y es raro que alguien se haya parado a mirar el de una dependencia que instaló hace tiempo.
Si un agente añade dependencias por ti, mete un paso antes de instalar nada: comprobar que el paquete existía antes de que el modelo lo sugiriera. Descargas, repositorio, historial. Con eso basta para cazar las alucinaciones estables antes de que lleguen a tu lockfile.
Y si nada de lo anterior te toca directamente, el consejo que vale para todos es el mismo de siempre: abre el árbol de dependencias de tu proyecto y cuenta mantenedores, no paquetes. Es el único número de esta historia que no cambia porque cambies de lenguaje.
Cimientos más grandes, blanco más grande
¿Por qué se está escribiendo tanto en Rust ahora mismo? Porque, por primera vez en mucho tiempo, seguridad, rendimiento y responsabilidad legal empujan en la misma dirección, y las herramientas para hacer el cambio han llegado a un punto en el que ya no hace falta ser un converso para dar el salto. Mi terminal va más rápido y mi sistema es algo más seguro, y no me ha costado nada de eso directamente.
Pero lo que de verdad me ronda la cabeza es lo que hemos cambiado por el camino. Hemos cambiado una familia de bugs que conocíamos muy bien por una superficie de ataque que sigue creciendo en direcciones que nadie tenía presupuestadas. Un modelo se inventa el nombre de una dependencia y alguien ya lo ha registrado antes de que termines de leer esto. Un millón de líneas se reescriben en once días y nadie las ha leído todavía. Cimientos más seguros, edificio más grande, y la misma cerradura barata en la puerta de entrada que llevamos años prometiéndonos cambiar.
No tengo un cierre limpio para todo esto. La migración merece la pena, los números de Android bastan para convencerme. Pero no es toda la respuesta, y quien la vende como si lo fuera acabará siendo el primero en sorprenderse con el próximo ataque a un paquete que todos daban por seguro.
Imagen: Pexels / Markus Spiske